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 😸

[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?

[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?)

silverstripe/vendor-plugin#34
silverstripe/silverstripe-module#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

[micschk]

... 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.

Thanks Peter! I tried to stay constructive and don't compare to contenders but indeed Laravel (& Livewire) are the 'elephant in the room'... I've started watching some vids on LaraCasts a while back (sort of what UncleCheese used to make for Silverstripe :-)). There's also some quite decent 'Laravel admin areas' comparable to ModalAdmin/Gridfield to pick from. Only thing really missing in Laraland is a CMS as solid als Silverstripe. How awesome would it be today had Silverstripe chosen to 'adopt' Laravel (& Vue) a few years back...

I intent to develop some small new projects on Laravel to get a better feel for it. The problem is that we have multiple longstanding (10y+) clients very deeply invested into Silverstripe for their websites and also some of their crucial business processes.

We've just (almost) finished migrating one of our bigger clients/websites to Silverstripe 4 (after a few smaller ones), the hours involved in this instance add up to about 250(!). These hours are 'necessary maintenance' and result in little to no actual added value to the client. Since all of this work & frustration is starting to add up, and this is not even our most complex system, a community (maintenance) fork of SS3 is actually starting to look like a feasible option. As I understand a few other small dev shops also have some systems too complex & big to migrate so they may be willing to support such an initiative.

Maybe even investigate if it'd be worth the effort to migrate the CMS to Laravel & tap into their enormous community & ecosystem at some point? (Sorry Uncle Cheese).

[spekulatius]

Yeah, I get that some people don't want to mention the 'elephant in the room'. For me, SilverStripe doesn't cover the same areas as Laravel does IMHO. I haven't replaced a SS site with Laravel or the other way around... I see Laravel is quite a different tool in the toolkit really. As you mention, the CMS side is definitely not on the level SilverStripe offers. My mention of Livewire truly comes from the good feeling it brings me coding (same as SS3 did).

My last project upgrade from SS3 to SS4 looked similar: Hundreds of hours and still only a partially happy client at the end. For very small sites a fresh start comes easier. Larger projects are often 'stuck'. I'm a bit worried about a long-term prospects of a community fork. It splits the small community further and leaves the good things SS4 has behind too. The main part many are unhappy with is React and complexity. I can't speak for the reasons led to this path, but it surely isn't helping SS.

[unclecheese]

I really feel like this megathread is starting to go around in circles, with the airing of half-sarcastic grievances followed by the presentation of the existential constraints we're dealing with, bringing focus back to the path forward, rinse and repeat. So I'll just restate a few key things:

My point is that the current way the UI functionality is build may be 'modern'

To reiterate, no one said that. The topic of this thread is modernising the CMS UI technologies. That's a process, not a point in time. It's a very difficult thing to do that puts us between two competing ideals -- a faster, more "modern" CMS UI, and a solid developer experience. Investing in one implicitly divests from the other given our obligations to backward compatibility and the size of our core team.

In retrospect, sure, we can have the conversation about whether doing a partial React migration was worth it in the long run given the maintenance costs versus just doing the whole lot at a much greater cost, but we made the best decision we could at the time, and the end goal remains the same.

Everyone agrees that the current state of React/PHP/Entwine purgatory is cumbersome and obtuse, but when we talk about modernising the CMS, it is, at the very least, a stepping stone, and I think this thread would be much more productive if it were focussed on where we want to be in terms of dev and user experience, rather than platforming numerous issues that we all know exist and promoting the use of other PHP frameworks as a solution to these problems.

[micschk]

I really feel like this megathread is starting to go around in circles, with the airing of half-sarcastic grievances followed by the presentation of the existential constraints we're dealing with and bringing focus back to the path forward

I tried not to sound sarcastic. What I actually meant to do is illustrate explicitly how some trivial customizations have now become roadblocks and are leaving me (and as far as I can tell at least some others) desperately scrambling for solutions. With this I tried to open up the "React is hard/not hard/hard in Silverstripe/deal with it" stalemate situation.

Please don't see it as an attack or attempt at forcing anyone's arm. It is however an honest attempt to get Silverstripe to reconsider and hopefully even adjust direction. I get that there's lots of devs who enjoy working with advanced tech stacks and that's your good right, and probably it seems like the obvious technical solution for the challenges at hand.

But my concerns involve business & community sense. Eg how does Silverstripe get their own clients to find it acceptable to pay for 250 hours on 'upgrading the CMS/framework'? And my questions on the size & involvement of the community were also meant honestly; is Silverstripe community growing or shrinking? Or (and that's also a possible answer) do you not keep track? Maybe even an implicit choice has been made to direct attention more towards a solid CMS product and less towards the 'golden age of customisation'? If so that's also valuable to know.

... a faster, more "modern" CMS UI, and a solid developer experience. Investing in one implicitly divests from the other given our obligations to backward compatibility and the size of our core team

That's exactly my concern; given the insights you as core devs have gained by now, do you still stand by this choice? Or is this 'sunk cost fallacy' in progress?

My numeration of files & lines of code involved into creating something as simple as a form in a modal, was meant to illustrate how much resources that small item must have extracted from an already small dev team. As (maybe naive) small development team, I think I'd halt any running project and re-evaluate the tech choices made if something seemingly trivial burned that much resources.

In retrospect, sure, we can have the conversation about whether doing a partial React migration was worth it in the long run given the maintenance costs versus just doing the whole lot at a much greater cost, but we made the best decision we could at the time, and the end goal remains the same.

That's exactly the discussion I hoped to start off. What exactly is that end goal (the initial goals stated by Sam?), and is that end goal still correct given what we know today? Did/does that goal sufficiently take clients & dev community into consideration? Can we (you) still consider other, more accessible/less involved routes to reach that goal?

To have this discussion, mentioning and comparing other frameworks and technologies seems necessary. Not as X is better than Y but to learn & see how others do stuff or solve comparable challenges and maybe save all of us some time (eg mix vs silverstripe-webpack). Conclusions don't have to be negative, for example one conclusion (for me) is that Silverstripe offers an incomparable CMS experience. But in case Silverstripe states they're not open to reconsider, any experiences other devs in the same situation have with alternative frameworks are very valuable to me.

Everyone agrees that the current state of React/PHP/Entwine purgatory is cumbersome and obtuse, but when we talk about modernising the CMS, it is, at the very least, a stepping stone, and I think this thread would be much more productive if it were focussed on where we want to be in terms of dev and user experience, rather than platforming numerous issues that we all know exist and promoting the use of other PHP frameworks as a solution to these problems.

I don't think that's exactly what was going on but maybe that's a viewpoint/framing-thing. Thing is; I'm aware the current situation is a stepping stone. To me in the current situation Silverstripe is comparable to SS3 in user-experience. But it's sadly a regression in business- and developer-experience.

As a developer, small dev-business owner and long time Silverstripe fan/advocate, I don't want Silverstripe to be here, let stand go further in this direction. So the most productive I can do is attempting to make things better by trying to get core devs to reconsider/re-evaluate instead of just defending past choices.

[sunnysideup]

Here are some questions:

• what can we do now to make the current, unsatisfactory, situation better?
• when do we expect to be in a better place?

[micschk]

Overall I must say I admire peoples continuous positivity around these issues.
Documenting a few recent insights & developments here for others as well.

Facing reality

MR giving an excellent presentation on this modern stack

Describing the move to modern UI tech as, well, not-yet-finished (trying to stay positive):

Win some, lose some
Some small ‘wins’ are mentioned, like the page history interface (which as I understand didn't turn out as re-usable as imagined) and Elemental Area recently having been fully moved to React.

Goodbye old-style fields
Having actually been bitten by that same chance (React-rendered Elemental) mid-way a project, my main takeaway is any custom fields became unusable due to this move (unless you invest extra time to make these fields React-rendered as well). I'm afraid this same situation will be coming up for fields used in GridFields once that becomes fully react-based (not sure).

As for what we can do to make the current situation better (@sunnysideup); I imagine some sort of compatibility/fallback layer for legacy fields would go a long way. Eg I see LiteralFields can be rendered via React, maybe good old .ss theme based fields could be rendered and passed to react as literalfield?

Community uptake (shrunk by about 30%)

BW giving a positive explanation on community activity declining

Headless use-case

UC explaining a possible use-case of the headless architecture beyond the CMS itself (personally enjoyed the casual mention of why one of Silverstripe's founders ‘ran off’(?) – spoiler alert: – something to do with this whole move to headless)

While looking at this presentation, I can not help but notice just of the amount of layers, files & buildtools this build process entails (and the maintenance nightmare & developer resource hog such a project would become). I honestly don't see how Silverstripe should be a backend/API framework for JS (React) based front-ends/apps and why anyone would want to build eg a company website this way. But again, maybe that's just me getting old. Interesting presentation though, thanks for that @unclecheese!

[unclecheese]

personally enjoyed the casual mention of why one of Silverstripe's founders ‘ran off’

Just want to be absolutely clear -- that was a joke. Ingo (who isn't a founder, but rather a long-standing member of the community and employee of the company), was a champion of headless, and I said that in jest, because it's the exact opposite of the truth. :)

I can not help but notice just of the amount of layers, files & buildtools

This one really surprises me.

• NextJS
• silverstripe-nextjs module
• NextJS siilverstripe plugin

Which layers were surprising to you, and what would you have expected? Even if the toolchain is more complicated, were you able to see the value proposition of headless that would offset that overhead?

[micschk]

Ah, I didn't get that you were joking. Made me smile either way :-)

Which layers were surprising to you, and what would you have expected? Even if the toolchain is more complicated, were you able to see the value proposition of headless that would offset that overhead?

Not necessarily surprising – it's more that I personally don't see why one would want build a page-oriented website this way (other than maybe it being 'new' and/or lead to slightly faster load times?). I really don't. Might just be a matter of personal preference but for me this setup seems overly complex (longer initial development + harder maintenance in the long run) at relatively little to no gain.

On the specific frameworks:

• In the case of Gatsby as I understand it you'd basically be 'static publishing' a whole site via Gatsby templates & platform? I don't see how that would be any better than just static publishing to a generic hosting?
• In the case NextJS I think you quite quickly would need to run a node server (you also mention this) and/or seem dependant on Vercel for hosting and deployment etc. And basically NextJS contains all the dynamic stuff like routing etc, so what, it will replace PHP altogether(?)

In general:

• How I understand this demo is that a dev would basically be moving SS's SQL querying/ORM from the PHP layer to the front-end JS/query.graphql files(?).
• So I think basically JS/react would be rendering HTML based on JSON data it gets by querying the GrapQL API, instead of PHP outputting HTML based on .ss templates(?).
• Then you'd need to run some node process to sort of 'build' the site and serve it over some additional hosting platform.

So no, I'm afraid I don't see the value proposition (of building complete sites as react apps).
Actually I'm starting to think I'm witnessing something that used to be a relatively simple process gradually turning into a sort of Rube Goldberg machine over the years.

As a side note I think Vercel also allows you to just define models in yml config and it will automatically build a database and GraphQL endpoints for you. So maybe someday we can rid Silverstripe of the PHP backend stuff altogether and just store everything on Vercel? (joking)

What I do get:

• I get that 'under the hood' the PHP GraphQL implementation may be totally different & speed-wise an improvement compared to SS's ORM(?), not sure about that. Anyway GraphQL in itself is and has been an obvious value proposition (to me).
• We have built data-based rendering/page components (also based on SS3) before, eg a course reservation system where the coursedates & available spots are loaded as 'live' JSON data. So I do see the benefit of this type of tech in data-rich applications/pages/components.
• But (as we're using VueJS) such a component is basically a matter of adding some extra markup in the .ss template file and a few lines of simple JS to have Vue update/render it based on live data. Not meant to start another framework war, just to illustrate the difference in the amount of files & build tools/steps etc.

So I do see a value proposition of data driven JS rendering, not necessarily of full-page JS apps (due to their relatively high overhead).

[sunnysideup]

tl;dr

I can report a mostly positive experience in making websites using NextJS and Silverstripe and we will do this with all our sites from now on.

long read

In case it helps, here is our experience building our first site. We are grateful for Aaron getting this up and running.... What I am also saying is: there is help out there getting started with this sort of thing.

CON:

• it was not faster than doing it old school, and I spent a lot of my own time, unpaid, fixing and learning things.
• what use to be simple now has many layers to it: basically, your PHP class goes to the basement of GraphQL, magic happens there, that is undecipherable to me, then pops up in NextJS land, and even there, the data travels through 3-4 layers to its final destination. That makes debugging harder than doing it the old way.
• writing react is a bit harder than writing html
• React is mainly working out how to turn small pieces of html into (re-usable) components. We could have simply done this better in *.ss files (and we already can).
• A lot of stuff that works out of the box in SS old school needed to be set up (e.g. 404 page redirection, old url redirection, etc... etc.... ). That remains a bit of a worry.

PRO:

• if you need a slideshow / video / whatever, it is likely you can find a couple of awesome packages you can install. The Silvestripe templating language was not set up to share front-end only solutions
• React / NextJS / NPM come with awesome debug tools. For example, if you have an error, you click on it and it takes you straight to your line of code that needs fixing (most of the time, sometimes the errors are more useless).
• you can write crap html, it is harder to write crap react components: you end up with better html / structure
• nextJS et al. have lots of other smart features that I don't understand, but offer speed advantages / rendering enhancements, etc... and they keep getting better, because lots of people use them.
• we have the most amazing webhost in the world (Jeff Bezos is not welcome in my home), and it was pretty straightforward to run a standard SS site and a nodeJS server on the same platform. www.sitehost.co.nz made it super easy for us. They have pre-configured docker containers. We just added a few changes in the config and we were up and running with NodeJS + PHP (using either NGINX or APACHE)
• long-term it will probably be faster than doing it the old school way.
• performance wise, the site just runs so fast and smooth. A lot of these funny "jQuery" animation glitches, where you spend a bit of time, trying to get the timing and sequence right: all gone!
• having the whole community use this approach means we can set up standards so that ultimately, it is easy again, we know where stuff lives, how it interacts, etc...

REALITY CHECK:

• for Silverstripe to survive, it needs to focus on a few things it is good at. Removing the templating language from the "things to do", is suspect having a third-party front-end machine is part of this move.

WOULD I DO IT AGAIN?
YES! We are now building another site in NextJs with great results

WOULD I DO IT AGAIN FOR A BROCHURE SITE?
YES! Because I like to do all our sites exactly the same way and given that it would not take much extra work (and over time be easier than old school), this is definitely a possibility.

WISH:

• a *.ss to *.jsx converter .... a tool to convert Silverstripe templates into react components would be useful at times, I am sure.

WORRY:

• I guess what I see a lot is that developers focus on new and shiny things because it helps their careers / makes them feel good and excited about stuff. That is mostly good, but also means that basically writing React / NextJs / etc... might actually not be any better / faster / easier to maintain than writing Vanilla html with JS / PHP / CSS all mixed in - basically WORST PRACTICE. Like, we have spent 20 years trying to make these amazing frameworks, but in some ways I feel we have come back to START, but just a lot more sophisticated kind of START.

[sunnysideup]

BUMPY MC BUMP A LOT

[vinstah]

tl;dr

I can report a mostly positive experience in making websites using NextJS and Silverstripe and we will do this with all our sites from now on.

long read

In case it helps, here is our experience building our first site. We are grateful for Aaron getting this up and running.... What I am also saying is: there is help out there getting started with this sort of thing.

CON:

* it was not faster than doing it old school, and I spent a lot of my own time, unpaid, fixing and learning things.

* what use to be simple now has many layers to it: basically, your PHP class goes to the basement of GraphQL, magic happens there, that is undecipherable to me, then pops up in NextJS land, and even there, the data travels through 3-4 layers to its final destination. That makes debugging harder than doing it the old way.

* writing react is a bit harder than writing html

* React is mainly working out how to turn small pieces of html into (re-usable) components. We could have simply done this better in *.ss files (and we already can).

* A lot of stuff that works out of the box in SS old school needed to be set up (e.g. 404 page redirection, old url redirection, etc... etc.... ). That remains a bit of a worry.

PRO:

* if you need a slideshow / video / whatever, it is likely you can find a couple of awesome packages you can install. The Silvestripe templating language was not set up to share front-end only solutions

* React / NextJS / NPM come with awesome debug tools.  For example, if you have an error, you click on it and it takes you straight to your line of code that needs fixing (most of the time, sometimes the errors are more useless).

* you can write crap html, it is harder to write crap react components: you end up with better html / structure

* nextJS et al. have lots of other smart features that I don't understand, but offer speed advantages / rendering enhancements, etc... and they keep getting better, because lots of people use them.

* we have the most amazing webhost in the world (Jeff Bezos is not welcome in my home), and it was pretty straightforward to run a standard SS site and a nodeJS server on the same platform. [www.sitehost.co.nz](http://www.sitehost.co.nz) made it super easy for us. They have pre-configured docker containers.  We just added a few changes in the config and we were up and running with NodeJS + PHP (using either NGINX or APACHE)

* long-term it will probably be faster than doing it the old school way.

* performance wise, the site just runs so fast and smooth. A lot of these funny "jQuery" animation glitches, where you spend a bit of time, trying to get the timing and sequence right: all gone!

* having the whole community use this approach means we can set up standards so that ultimately, it is easy again, we know where stuff lives, how it interacts, etc...

REALITY CHECK:

* for Silverstripe to survive, it needs to focus on a few things it is good at.  Removing the templating language from the "things to do", is suspect having a third-party front-end machine is part of this move.

WOULD I DO IT AGAIN? YES! We are now building another site in NextJs with great results

WOULD I DO IT AGAIN FOR A BROCHURE SITE? YES! Because I like to do all our sites exactly the same way and given that it would not take much extra work (and over time be easier than old school), this is definitely a possibility.

WISH:

* a *.ss to *.jsx converter .... a tool to convert Silverstripe templates into react components would be useful at times, I am sure.

WORRY:

* I guess what I see a lot is that developers focus on new and shiny things because it helps their careers / makes them feel good and excited about stuff.  That is mostly good, but also means that basically writing React / NextJs / etc... might actually not be any better / faster / easier to maintain than writing Vanilla html with JS / PHP / CSS all mixed in - basically WORST PRACTICE. Like, we have spent 20 years trying to make these amazing frameworks, but  in some ways I feel we have come back to START, but just a lot more sophisticated kind of START.

Have you considered, using prisma or other DB ORM and connecting to the same DB as silverstripe? that way you don't need to rely on graphql requests

[sunnysideup]

Have you considered, using prisma or other DB ORM and connecting to the same DB as silverstripe? that way you don't need to rely on graphql requests

Interesting idea. Would it understand the layered cake that is SS DB (e.g. get data from SiteTree, Page, and MyPage to get all the details for MyPage)?

[michalkleiner]

Have you considered, using prisma or other DB ORM and connecting to the same DB as silverstripe? that way you don't need to rely on graphql requests

Interesting idea. Would it understand the layered cake that is SS DB (e.g. get data from SiteTree, Page, and MyPage to get all the details for MyPage)?

For other tools the Silverstripe CMS db is just a relational db like any other. You'd need to let it know what and how you want queried, what tables to join etc.

[sunnysideup]

For other tools the Silverstripe CMS db is just a relational db like any other. You'd need to let it know what and how you want queried, what tables to join etc.

SO then why not use SS GraphQL? I mean, what we are trying to do is to simplify it all.

[michalkleiner]

For other tools the Silverstripe CMS db is just a relational db like any other. You'd need to let it know what and how you want queried, what tables to join etc.

SO then why not use SS GraphQL?

It wasn't my suggestion above, so don't know about the context there. I only mentioned that any other ORM/tool would need some massaging to understand/work with the SS db structure.