Should we decouple Drupal with a client-side framework?

Honestly, Drupal is doomed. I wrote about it years ago when I left the community [1] around the time many of the smart folks who were contributing started moving on to better things.

Just a look at Google Trend for Drupal [2] shows you that it's been declining steadily since 2009. Comparing it to Wordpress [3] shows you the extent of the gap with the leader.

Drupal has always been stuck trying to address an odd user; not exactly a developer, but somebody technical enough to leverage the insane amount of configuration interfaces that allow you to compose a Drupal website.

Personally, I think most CMS have it wrong: coupling content management and front-end generation is a sure way to end up spreading yourself thin and not properly addressing either problem. I think content API (e.g. Prismic.io or Contentful) are good examples of what a better approach could be.

Have a content management system that has great editorial tools and exposes the content through an API and let developers do what they do, integrating the content from the API.

[1]: http://teddy.fr/2013/01/25/dropping-the-drop/

[2]: https://www.google.com/trends/explore#q=drupal

[3]: https://www.google.com/trends/explore#q=drupal%2C%20wordpres...

It's tough to see the healthy path forward for Drupal. 10 years ago it filled an obvious need. But now that need is getting squeezed from both sides. On the low end, for a company that only needs a simple-to-moderate CMS, there is WordPress. But on the other side, where many complex modules are needed, think about how easier it is now to pull together a bunch of modules using one of the new services that automates microservices. Think of something like lsq.io. Suppose you need 19 modules, so you roll out 19 simple Node apps, each basically just some Node package, and then a service like lsq.io automates the orchestration and deployment of those 19 modules. Is that more difficult than Drupal? I would argue that in most cases it is easier.

So what set of needs exists for which Drupal is the perfect answer? That set of needs is getting smaller all the time, as other options get better. "Easy to configure CMS" is still the best bet for Drupal. That is what it was originally known for. That was what let it win the competition with ExpressionEngine and Joomla.

If Drupal focused on stability, they could claim to be the stablest answer for configurable CMSs. That is probably a niche it could hang on to for another 5 years. Beyond that... its tough to see where it goes after that, but at least that is something to hang on to.

There are so many other things that need fixing first. They should spend some time getting all the most used modules to use the same UX. Panels looks and acts totally differently to Views, both of which are totally different to Blocks.

We found a module the other day that had a Delete TAB, not a button, not a link but a TAB. Honestly. Who does that?

Sometimes the save button is at the bottom, sometimes the top, sometimes it saves via AJAX...

What they should do is like the module HOOK system, do the same for the user experience/GUI front end.

And Drupal is so slow. So painfully slow. Install a few modules and e-commerce and wow. Slow. Slow. Slow.

And as soon as you start debugging it, nearly all the code ends up being along the lines of:

    $function($args);

due to the HOOKs. When you're five or six levels deep and the call stack is just full of $function() calls... what then?

Drupal needs to decide what it is, do that well. It needs to decide what it wants to be, and optionally also work toward that.

I hate to see its evolution as never-quite-there toward a never-quite-decided future.

Whatever they do, the years-long release cycle needs to die, allow whatever improvements you'd like on head without worrying much about BC, occasionally cut off a LTS release that never gets anything new without 100% BC. Maintain these long enough that it's economically feasible for people to base projects on (Whatever the benefit of the project is * years that benefit is durable > cost of development). Focus on data migration for when people re-build sites on newer platform instead of continuous upgrades -- nobody does these unless they're painless, they will never be painless.

There's too much coupling between presentation, client-side behavior, server-side behavior and data model for me to see this particular change going anywhere good.

You can't truly decouple client and server while still letting non-developers build web apps unless you build a UI-configurable framework for consuming an API generically and building client-side presentation and behavior. Even then, unless you also go so far as to infer things about my data from its API, it's still twice as much work to describe both my server-side domain model and its presentation instead of letting one be implied by the other.

But in typical Drupal fashion, they probably don't mean "decouple" when they say that word, so it's really just rewriting the current hodge-podgy fully-coupled client-side behaviors in a more structured but still coupled way using a client-side framework -- absorbing it the way they did Symfony for the server, not the best move but definitely with value and very achievable.

Given Drupal's highly-modular architecture, React and a manager like Redux makes the most sense IMO.

Building the Drupal module frontend as React Components seems like it would be easy to add on as a toggleable layer. You push state into the global Drupal root and mimic the module tree in the state store, and then reduce based upon a dispatch from individual modules somewhere in the document tree.

It's a very clean fit into Drupal's legacy architecture and easy for a Drupal developer to wrap their head around, as it's all one-way.

Is there market evidence that websites are getting penalized for serving up html and not using client-side frameworks?

Yes, that's where things are going. The vast majority of websites out there never really needed 18-wheeler CMSs to move a small box. The vast majority of web dev shops cannot afford a full-time fully qualified ops/server admin employee. Conclusion: serverless architectures are the obvious answers for most websites and web apps. For the two or three must-be-done-in-server processes, services like AWS Lambda will do (or APIs from vendors). Turn Drupal into a PAAS with an API that any front-end CMS can use. I've already tested this hypothesis with a few small/medium sized clients (size measured in traffic and user base). It works. I had to put together a simple CMS (backbone+bootsrap) but it would be nice to see a popular CMS with themes + plugins going into this direction.

This seems like a gross mis-understanding of your product. Content sites are still almost entirely regular web pages, not any of the fancy new "single page app" stuff.

Realistically, the selling point of Drupal is the strong integration between the front end and the back end - if Headless Drupal becomes the norm, there won't be a lot of good reasons to deploy Drupal on the back-end instead of say, Rails API.

If the Drupal project gets solidly behind Angular, React, Ember, or something else, and Drupal 9 modules support client-side as well as server-side rendering, this could be a very interesting development.

How will this impact SEO? Have any other CMSes managed to take the SPA route successfully?

yes

This is a terrible idea, and will destroy Drupal, but other than that, sure why not?